home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20021006-20030409
/
000316_fdc@columbia.edu_Sun Feb 16 16:52:11 EST 2003.msg
< prev
next >
Wrap
Text File
|
2003-04-08
|
3KB
|
77 lines
Article: 14112 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.unix.misc,comp.protocols.kermit.misc
Subject: Re: Nasty nulls in FTP
Date: 16 Feb 2003 16:51:17 -0500
Organization: Columbia University
Lines: 60
Message-ID: <b2p14l$5f7$1@watsol.cc.columbia.edu>
References: <1194685a.0302131007.4d6c674f@posting.google.com> <m1wuk37a6p.gnus@usa.net> <3e4ccd43$3_3@news.iglou.com> <nasty.nulls.on.the.internet@helpful.aq>
NNTP-Posting-Host: watsol.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1045432281 17771 128.59.39.139 (16 Feb 2003 21:51:21 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 16 Feb 2003 21:51:21 GMT
Xref: newsmaster.cc.columbia.edu comp.unix.misc:59682 comp.protocols.kermit.misc:14112
In article <nasty.nulls.on.the.internet@helpful.aq>,
Helpful Observer <observer@helpful.aq> wrote:
:
: On 13 Feb 2003 10:07:47 -0800, generic*arigatoo.net wrote...
: >
: > I'm transferring files from a OS/3900 mainframe to a Unix box. The
: > mainframe data contains nulls (x00), which causes lines in the data to
: > be truncated in transit.
: >
: > Is there an FTP option to handle this?
:
: Somebody gave advice to simply use the 'binary' mode of the
: FTP protocol. This may not be the whole problem.
:
: First of all, I suggest that you consider whether some part
: of this IBM-mainframe data is textual, with characters encoded
: in EBCDIC, rather than in ASCII. Hardly any computers other
: than IBM mainframes use EBCDIC these days, and your Unix
: machine will need to see ASCII. Converting between the two
: encodings is possible but there are pitfalls for the unwary.
:
FTP text mode these days means ASCII; the client sends TYPE A
and the server agrees or not. If it disagrees, the client
presumably stops right there; therefore if you downloaded in
text mode, the server should have translated EBCDIC to ASCII.
But if it really is text, you still wouldn't find NULs in it.
At least not unless they are record padding or somesuch.
In that case, there's always the chance the file was transferred
correctly, but your Unix software stops when it sees a NUL.
If you load the file into EMACS, you might be pleasantly surprised
to see the whole thing, but with a bunch of ^@'s mixed in, which
you can easily remove.
: Another poster mentioned Kermit, and that's not a bad idea,
: since the Kermit protocol was designed to be able to handle
: data transfers involving EBCDIC-to-ASCII translation. Try
:
: http://www.columbia.edu/kermit/
:
: BUT, is the data really a pure stream of text characters, or is it
: data with some arbitrary encoding?
:
Exactly. File transfer is one thing, application-specific data
conversion is another, usually accomplished by "export" and "import"
functions in the application itself. In any case IBM Mainframe
Kermit gives you some options to deal with different record formats,
depending on the underlying OS (CMS, TSO, etc). IBM Mainframe
Kermit is here:
http://www.columbia.edu/kermit/k3270.html
: I hope you are not expecting
: to copy a DB2 database from the IBM machine and plop the raw
: file onto some Sun box running Oracle and watch it 'just work'!
:
Right. Not only is character encoding different, so (in all
likelihood) is internal format for numbers and other data types.
- Frank